home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ien / ien-104 < prev    next >
Encoding:
Text File  |  1988-12-01  |  10.6 KB  |  232 lines
  1. IEN 104
  2.  
  3.  
  4.  
  5.              Minutes of the Fault Isolation Meeting
  6.  
  7.                          12 March 1979
  8.  
  9.  
  10.                       Virginia Strazisar
  11.  
  12.  
  13.  
  14.                     Bolt, Beranek, and Newman
  15.  
  16.                           20 March 1979
  17.  
  18.  
  19. Minutes of the Fault Isolation Meeting held at BBN on March 12
  20.  
  21. Attendees:
  22. Virginia Strazisar, BBN, chairman
  23. Peter Sevcik, BBN
  24. Dale McNeill, BBN
  25. Noel Chiappa, MIT
  26. Ray McFarland, DOD
  27. Mike Wingfield, BBN
  28. Jack Haverty, BBN
  29. Bill Plummer, BBN
  30. Mike Brescia, BBN
  31.  
  32. Ginny suggested that there are three situations  in  which  fault
  33. isolation  is  needed:   1) the user at a terminal on the catenet
  34. who cannot reach some destination on the catenet,  2)  a  catenet
  35. control  center  that  must decide what network or gateway in the
  36. catenet has failed, and  3)  the  gateway  implementor  who  must
  37. decide  what part of the gateway hardware or software has failed.
  38. These situations were put forth as a framework for discussing the
  39. types of fault isolation facilities that we need.   Ginny  stated
  40. that  the  object  of  the meeting was to draw up a list of fault
  41. isolation tools needed,  giving  special  consideration  to  what
  42. situations  each  of  these  tools  would  be  used  in  and what
  43. questions they could be used to  answer.   From  the  suggestions
  44. drawn up at the meeting, the detailed formats and protocols could
  45. be designed; this level of design was specifically avoided at the
  46. meeting.
  47.  
  48. The first situation discussed was the user at a catenet terminal,
  49. who  discovers  that  he  either  cannot  connect to a particular
  50. destination host or that he no longer gets any response from  his
  51. previously  working  connection.   At  present  no information is
  52. passed to the user in either of  these  cases.   Everyone  agreed
  53. that  the user should receive some error reply.  It was suggested
  54. that the user should receive a response indicating that either 1)
  55. the destination host is unreachable,  2)  the  local  gateway  or
  56. network  is unreachable or 3) the catenet is inoperational.  Most
  57. people agreed that the naive user does not care to know what  the
  58. catenet  problems are in any more detail than this.  For example,
  59. an error messgage of the form "Can't  reach  destination  network
  60. because  gateway 3 is down" would be totally useless to the naive
  61. user.  The user also wants to  know  when  the  service  will  be
  62. restored,  either  "within  a  short  time" such that the user is
  63. willing to wait for the service to be restored;  or  "not  for  a
  64. long time" such that the user will quit trying to use the service
  65. at   this   time.    Several  people  pointed  out  that  a  more
  66. sophisticated user may want to know exactly what component of the
  67. catenet failed.  There was some discussion as  to  whether  users
  68. should  be  given access to tools that would enable them to probe
  69. the catenet gateways to determine  where  the  failure  occurred.
  70.  
  71.  
  72.  
  73.  
  74.  
  75.  
  76. The consensus of opinion was that the user should be given access
  77. to  such  tools,  but that no user should be required to use such
  78. tools.  Our model was that the naive user on receiving  an  error
  79. message  would  call a network or catenet control center, whereas
  80. the more sophisticated user may attempt to track down the problem
  81. before contacting the  control  center.   We  discussed  in  more
  82. detail  what  sort of message a gateway could return to the user.
  83. It was suggested that if the network returned  an  error  message
  84. about  a  specific  host that that error message (text) should be
  85. returned verbatim to the user.  It was also suggested that  error
  86. codes be defined for "common" failures, i.e. net down, host down,
  87. and  that these be included in the error message.  It was pointed
  88. out that the gateways currently return  messages  to  the  source
  89. host  if  they  believe (based on their routing information) that
  90. the destination network is unreachable.  These  messages  contain
  91. the  source and destination addresses and the protocol field from
  92. the original datagram.  Several  people  pointed  out  that  this
  93. information  is  insufficient  to  return an error message to the
  94. source user and that the entire internet header of  the  original
  95. datagram  should  be returned in the error message.  We discussed
  96. the problem of what to do in the case where datagrams are lost in
  97. a gateway or network in such a manner that no  error  message  is
  98. generated  and  returned  to  the source.  It was decided in this
  99. case that the source host should automatically probe the gateways
  100. in order to return a reasonable status message to the  user.   It
  101. was  assumed  that  the user is running a program that implements
  102. some type of internet  protocol,  such  as  TCP,  and  that  that
  103. program   is   capable   of  detecting  long  delays  or  mutiple
  104. retransmisssions and of generating some type of probe  packet  to
  105. attempt  to  track  down  the  failure when this occurred.  These
  106. probe packets are discussed in more  detail  below.   Information
  107. obtained  from  such  probing  could also be sent to a monitoring
  108. center.
  109.  
  110. We discussed the concept of a monitoring or control center.   The
  111. primary  purpose  of  a  monitoring or control center in terms of
  112. fault isolation is to isolate the component (network or  gateway)
  113. that  failed and to notify the proper authority to have it fixed.
  114. We felt that a control center was needed to avoid having all  the
  115. users  in  the catenet calling any and all implementors they felt
  116. might be responsible for  problems.   The  concept  of  a  single
  117. control  center was discussed and rejected for both technical and
  118. political reasons.  From the technical  point  of  view,  it  was
  119. pointed  out  that the catenet could become partitioned such that
  120. the control center was cut off from part of the catenet and  thus
  121. could no longer handle faults in that portion of the catenet.  On
  122. the  political  side,  it  was  pointed  out  that  organizations
  123. responsible for the  individual  networks  may  be  unwilling  to
  124. support  one  control  center run by one organization.  We agreed
  125. that the catenet  control  center  should  actually  be  multiple
  126. control  centers.   These  could  be  either the existing network
  127.  
  128.  
  129.  
  130.  
  131.  
  132.  
  133. control centers  working  in  co-operation  or  separate  catenet
  134. control  centers,  each  of which was established by co-operating
  135. network groups.  Tools that  these  control  centers  would  need
  136. included  a  facility  to  probe  gateways  to  determine  why  a
  137. particular destination was unreachable.
  138.  
  139. We elaborated slightly on the design of a  facility  for  probing
  140. gateways.   A  host  or  control center sends its local gateway a
  141. message saying "poll the gateways in the catenet to determine why
  142. I can not get to destination X".   The  gateway  then  polls  its
  143. neighbors,  its  neighbors'  neighbors,  etc., extracting routing
  144. tables,  addresses  of  neighbor  gateways,  status  of  neighbor
  145. gateways  and  networks, etc. to determine why the destination is
  146. unreachable.  The gateway would then formulate a response to  the
  147. host;   this  response  would  be  of  the  form:   "the  network
  148. connection between gateway 3 and net 2 is down", "gateway  5  and
  149. gateway  6  are down", etc.  This mechansim would be an extension
  150. of the gateway-gateway protocol as  defined  in  IEN  #30.   This
  151. probe  facility  would  be  used by the source host to generate a
  152. message to the user in the case where  no  response  is  recieved
  153. from  the  destination  and  no  error message is returned by the
  154. gateways.  The facility would also be  used  by  catenet  control
  155. centers to isolate the componenet of the catenet that has failed.
  156.  
  157. It  was  pointed  out  that  we should be concerned not only with
  158. total failures, but  also  with  system  performance,  especially
  159. delay.   In  this context, we were not concerned with cases where
  160. delay seemed slightly longer than  usual,  but  rather  cases  in
  161. which  traffic  crossed  the catenet with extrememly high delays,
  162. i.e several minutes.  A facility was suggested to track this sort
  163. of problem:   generate  a  packet  from  source  A  addressed  to
  164. destination  B; have this packet trace its route and timestamp it
  165. at each gateway on the route to B; at B, echo the packet;  return
  166. the  packet  to the source, A, using source routing and the route
  167. stored in the packet via  the  trace  mechanism;   timestamp  the
  168. packet  on  its  route  back  to A.  The timestamps in the packet
  169. could now be interpreted  to  yield  transit  times  across  each
  170. network  as  there would be a pair of timestamps for each gateway
  171. traversed.
  172.  
  173. The final stage of fault isolation is the situation in which  the
  174. failure  has  been  attributed  to  a  particular gateway and the
  175. implementor of that gateway must debug it.  This  part  of  fault
  176. isolation  was not discussed in detail.  It was suggested that at
  177. this point, it would be very  useful  to  be  able  to  turn  off
  178. timeouts  in the catenet to avoid having the state of the catenet
  179. change in such a way that the problem can no longer be  isolated.
  180.  
  181. In  summary,  the following list of tools and situations in which
  182. they would be used was suggested.
  183.  
  184.  
  185.  
  186.  
  187.  
  188.  
  189.  
  190. 1)  Error messages indicating whether the destination  host,  the
  191. local  network  or  gateway,  or  the  catenet  had  failed,  and
  192. indicating the time at which service should be restored.
  193.  
  194. These are to  be  returned  automatically  to  the  catenet  user
  195. whenever there is a failure in using a catenet service.
  196.  
  197. 2)   Gateway  to  gateway probing mechanism that can be initiated
  198. with a host to gateway message.
  199.  
  200. This mechanism would be used by a control  center  to  isolate  a
  201. component  failure.   It would also be available to the user.  It
  202. would be used by source host protocol programs  to  formulate  an
  203. error message for the user when no repsonse was received from the
  204. destination  and no error message was received from the gateways.
  205.  
  206. 3)   Ability  to  trace,  echo  and  source  route  packet   with
  207. timestamping.
  208.  
  209. This  facility  would  be  used  to  determine  where  delays are
  210. occurring when a destination is reachable, but delays  cannot  be
  211. accounted for.
  212.  
  213. 4)  Ability to echo packets off any gateway.
  214. 5)  Ability to trace packets.
  215. 6)  Ability to source route packets.
  216. 7)  Ability to dump gateway tables.
  217. 8)  Ability to trace packets by sending replies from every
  218. gateway that handles the packet.
  219.  
  220. These  capabilities  would be used by control centers and gateway
  221. implementors to  isolate  failed  components  and  determine  the
  222. reasons  for  failure.   These  facilities  were not discussed in
  223. detail.  A description of  mechanisms  for  tracing  packets  and
  224. source  routing packets was given in IEN #30, although these have
  225. not yet been implemented.
  226.  
  227. The next step in developing fault isolation  mechanisms  for  the
  228. catenet  is  to  work  out the detailed design for the mechanisms
  229. suggested above, and to implement these in  hosts,  gateways  and
  230. control centers.
  231.  
  232.